Policy Settings
In This Topic...
The Policy Settings page is used to define rules and configuration settings for the generation of submissions and policies.
With the master cover selected, click the Policy Settings item in the Screens widget. For instructions on finding and viewing a master cover, see the section on Viewing and Modifying a Master Cover.
Identifies the product associated with the master cover. |
|
Identifies the current status of the master cover. |
The Types panel defines a variety of lists used throughout the submission process. Fields marked with a red asterisk * are required.
The effective coverage period is the period between the Effective Date and the Valid Until date. The Effective Policy Transaction Period Settings control the rules for how the period is determined.
This panel is collapsed by default, but can be expanded using the icon.
Depending on your business needs, you may want to hide the Effective Date and Valid Until date fields in the Policy Information widget and detail window. This is common when using a fixed policy term, but could also be necessary for various other reasons. The Hide Effective Coverage Period Panel feature allows the fields to be hidden based on any combination of transaction type, transaction status, and the security roles assigned to the user.
Note: The fields are only hidden if the transaction and user match at least one selected option in each group. At least one option must be selected in each group or the fields are never hidden.
If the fields are hidden, and the user does not have the necessary security role to view the other details in the Policy Information widget, the entire widget is hidden.
Select the transaction types for which the panel should be hidden. |
|
Select the transaction statuses for which the panel should be hidden. |
|
Select the user security roles for which the panel should be hidden. |
The Endorsement and Adjustment Settings panel provides settings for how endorsement and adjustment transactions are created and how they affect other transactions.
Allow Adjustments | Allows Adjustment transactions to be created. Adjustments are used to make changes to the policy coverage for a specific period within the term. |
Allow Endorsement Contractions | Allows Policy Term Contraction transactions to be created. This is a type of Endorsement transaction that can be used to shorten the Effective Period of a Bound policy term. When an Endorsement Contraction is initiated, the transaction transitions to Endorsement - Incomplete status. |
Set Endorsement Contraction Date to | This field is displayed when the Allow Endorsement Contractions checkbox is checked. Select one of the following options. |
The date is set to the current system date upon which the Endorsement Contraction is initiated. | |
On creating a Policy Term Contraction, the date is copied from a field in the workflow. On Calculate Quote, if there is a value withing the term, the Contraction Date is set to this value. If outside the term period, either the term Effective Date or Valid Until Date is used, depending which is closer to the Contraction Date. |
|
Select Field | This field is displayed when Field Value is selected for the Set Endorsement Contraction Date to field. Select a field from the workflow. |
Prompt for Endorsement Contraction Date |
When checked, users will be prompted to enter the Contraction Date of a Policy Term Contraction into a detail window when they click on Contract in the Actions widget. This field is displayed when Default is selected for the Set Endorsement Contraction Date to field. |
Allow Out of Sequence Endorsements (OOSE) | Allows Endorsements to be created with effective dates that are earlier than other bound endorsements. |
If unchecked, new endorsements can only start on the same or later date than the most recent bound endorsement, and the Valid Until date must equal the end of the term or later. | |
If checked, endorsements can be created at any point in the term, and the Valid Until date can be any date after the Effective Date. | |
This setting does not apply to Endorsement Contractions. | |
Note: It is recommended that OOS changes only be enabled for new Products, as this functionality could have unintentional effects on existing policies. For additional information, see the Out of Sequence Endorsement and Adjustment Changes section. |
|
Update Blocking Endorsements / Adjustments with Out of Sequence Changes | This option requires that Allow Out of Sequence Endorsements be checked, and both the Set Endorsement Effective Date to and Set Adjustment Effective Date to fields must be set to Default. |
When creating an out of sequence endorsement or adjustment with this setting checked, any endorsement or adjustment transactions with an Effective Date after that of the new transaction are considered blocking transactions. On binding the new transaction, all blocking transactions are voided and then replaced with new versions that reflect the changes in the new transaction. For a detailed description of how the blocking transactions are modified, see the Out of Sequence Endorsement and Adjustment Changes section. | |
On checking this option, Prompt for Endorsement Effective Date is automatically checked and hidden, Restrict Endorsements to Last Policy Transaction is automatically unchecked and hidden, and Endorsement Source Transaction is set to Latest Effective and hidden. | |
If this setting is unchecked, endorsements and adjustments will not cause any changes to other transactions. | |
Prompt for Endorsement Effective Date | This option is checked and hidden if Update Blocking Endorsements / Adjustments with Out of Sequence Changes is checked. In addition, this option requires that Set Endorsement Effective Date to be set to Default. |
When checked, users will be prompted to enter the Effective Date of an endorsement into a detail window when they click on Endorse in the Actions widget. If Update Blocking Endorsements / Adjustments with Out of Sequence Changes is checked, this will also apply to adjustments. | |
When the detail window opens, the Effective Date field will be populated with a date by default. If the current date is within the policy term, it will appear by default. If the current date is later than the policy term’s Valid Until Date, the policy term’s Valid Until Date will appear by default. If the current date is earlier than the policy term’s Effective Date, the policy term’s Effective Date will appear by default. | |
When not checked, the system will use the Effective Date based on the selection of the Set Endorsement Effective Date to field. | |
Restrict Endorsements to Last Policy Transaction | This option is unchecked and hidden if Update Blocking Endorsements / Adjustments with Out of Sequence Changes is checked. |
When checked, this setting only allows endorsements to be created from the most recent transaction per policy term. The transaction must be Bound to allow endorsement. If the transaction is Declined, the next most recent transaction is enabled for endorsement. | |
This setting applies to all Endorsements, including Endorsement Contractions. | |
Endorsement Source Transaction | This option is set to Latest Effective and hidden if Update Blocking Endorsements / Adjustments with Out of Sequence Changes is checked. If Restrict Endorsements to Last Policy Transaction is checked, then this option will be set to Default on saving. |
This option determines how the system should select a policy transaction from which to create an endorsement. When Default is selected, the data will be copied from the transaction used to initiate the endorsement. When Latest Effective is selected, the data will be copied from the latest bound New Business, Renewal or Endorsement transaction whose coverage period includes the endorsement’s Effective Date, and whose CorrectionType is not Void or Offset. | |
This setting applies to Endorsement Contractions. |
The Claims-made Settings panel is displayed when the Product Type is set to Claims-made on the General Information page.
Allow ERP Endorsement | If checked, this setting allows for Claims-made policies to offer extended reporting period coverage on policies associated to this Master Cover. |
ERP Endorsement Duration List |
This field is displayed when the Allow ERP Endorsement setting is checked. Select the ERP duration option list configured in the Workflow Container associated to the Master Cover. |
Note: The ERP Duration List must be created as an Option List when configuring the Workflow. For details on the ERP Duration List resource type, see the Managing Option Lists section. |
|
ERP Endorsement Duration Default |
This field is displayed when the Allow ERP Endorsement setting is checked. Select the default period in years for the ERP Endorsement. |
One field can be defined as containing the insured value of the policy. The drop down lists all fields in the attached workflow that have been set as Rate Driver fields. The selected field is available for reports, identified as the insured value. |
|
A field can be selected to override the displayed statuses in the workflow. The drop down lists all Textbox and Label fields from Form panels in the attached workflow. |
|
|
If the field contains a value, either selected manually or calculated, it will be displayed in the Status fields of the Policy Information widget (without the color coding) and the Policy Information window, as well as the Status column of the Policy Transactions list. If the field does not have a value or if the value is blank, the status will revert back to the core system statuses. |
|
This only affects the display of the status fields in the workflow. The core system statuses still apply, and still control all aspects of the transaction. Features such as available Actions, workflow overrides, and other resources associated to transaction statuses will not be affected. For reference, the transaction types are still displayed in the Type column of the Policy Transactions list. |
Once a quote has been issued on a transaction, either automatically or manually, this option allows users to submit a special request for a new quote. |
|
Allows users with the appropriate rights to issue a quote where certain settings or values would normally be rejected by the Quote Validation rules. |
|
Set Transaction Status to Incomplete if Quoted Submission is Modified |
If checked, any changes to a transaction in Quoted or Underwriting Required status will cause it to revert to Incomplete status on saving, instead of recalculating the quote. The transaction can then be re-quoted, either manually or automatically. |
Note that this is in addition to any other settings that may set a transaction back to Incomplete, such as validations. | |
Allows Declaration transactions to be created. Declarations are used to provide required coverage information on a regular basis. |
|
|
Enabling declarations causes monthly periods to be automatically defined on binding a new business or renewal transaction. An endorsement that extends the term may also generate additional periods. The periods will include the first month of the term (including a partial month) to the last full month of the term. If the term ends partway through a month, that last month will be covered in the renewal. |
Allows alternate versions of an unbound New Business or Renewal transaction to be created. These quote versions are created to present additional choices with minor or major variations. |
|
|
Quote versions are handled the same as normal transactions, with quoting and referrals. When one version is bound, all alternates are put into Lost status. |
Allows users from underwriter companies to create new clients and edit the client information in submissions. If unchecked, the underwriters are not allowed to create or edit clients. |
|
|
This permission only applies within submissions created under this Master Cover. The user will also need to have the required security rights. |
Allow Program Policies | Allows policy terms to participate in Master / Underlyer relationships through the Program Policy feature. This allows applicable policy terms to be designated as a Parent Policy, and/or available to be linked to a Parent Policy as a Child Policy. |
This permission only applies to submissions created under this Master Cover. The user will also need to have the required security right and data management rights to manage these associations. This setting is only available when the Product Type field in General Information page is set to Occurrence-based. |
|
For additional information on managing Program Policies, see |
|
When quotes have been calculated but a specific quote has not yet been selected, the Premium widget displays a default quote. Select how that default quote will be determined. |
|
Of the suitable quote options, the one with the lowest premium will be displayed. |
|
Of the suitable quote options, the one with the lowest sequence number will be displayed. |
|
This setting specifies if the system should send one e-mail to all recipients, or multiple copies. |
|
Individual copies of the e-mail will be created and sent for each recipient in the To and Additional To fields. This option will cause recipients in the Cc and Bcc fields to receive multiple copies of the e-mail. |
|
|
Each recipient in the To and Additional To fields will not be able to see the other recipients in these fields. |
A single e-mail is created and sent to all recipients. Each recipient in the To and Additional To fields will be able to see the other recipients in these fields. |
When the user takes certain actions within the system, they can be required to enter a note associated with the action. Check the boxes for all actions where a note should be mandatory. |
The Coverage Calculation Methods panel allows you to specify the calculation method to be used when the system calculates the policy premium for a specified transaction type.
Select the calculation method to be used when the system calculates the transaction’s premium, taxes, fees and commissions. |
|
The refunded premium will be determined by prorating the policy’s premium, taxes, fees and commission using the cancellation’s effective date. |
|
For details on how prorating calculations are performed, see the Prorating and Adjustments section. |
|
The refunded premium will be calculated using premium values from one or more dynamic fields in the workflow, according to configured Rate Rules. The premium values can be produced by calculated fields, or brought in from external systems. Multiple rules can bring in values for multiple premium types, including adding together multiple values for each premium type. Taxes, fees, and commissions are then applied to each premium type using their respective settings. Each premium type is rounded according to the Rounding Precision and Rounding Style specified in the Master Cover - General Settings page. |
|
Select the calculation method to be used when the system calculates the transaction’s premium, taxes, fees and commissions. |
|
The premium is set to reverse any refund calculated for the associated cancellation transaction. |
|
The premium will be calculated using premium values from one or more dynamic fields in the workflow, according to configured Rate Rules. The premium values can be produced by calculated fields, or brought in from external systems. Multiple rules can bring in values for multiple premium types, including adding together multiple values for each premium type. Taxes, fees, and commissions are then applied to each premium type using their respective settings. Each premium type is rounded according to the Rounding Precision and Rounding Style specified in the Master Cover - General Settings page. |
The Premium Type - Rating Basis panel defines the driver fields containing the rating basis for each premium type. This is used to calculate the technical rate.
All premium types available for the current master cover are listed. Any field set as a Rate Driver from the attached workflow can be assigned to any premium type. The content of the fields could be entered directly by the user, or could be a calculated field deriving the value from a variety of data.
Individual premium types can be excluded from the prorating and adjustment calculations.
Check all premium types that should not be prorated when performing calculations. The selected premium types are always calculated according to a period of one full year. |
|
Check all premium types that should not be adjusted when performing calculations on endorsements. The selected premium types are not modified by other transactions. |
See Prorating and Adjustments for more information.
The Attachment Type Settings panel is automatically populated with the options from the Attachments list selected in the Types panel. If the list is changed and the page saved, the new options will be added and any previous options that have been assigned security roles will remain in the panel for reference, but cannot be selected for new attachments, while previous options that have no security roles will be deleted.
By default, no security roles are assigned to attachment types, meaning any user can select the type when attaching files, and all users will have access to the attachment. Once security roles have been assigned, a user will need to have at least one of those roles in order to select the attachment type when attaching files, and to view attachments with that type.
- To assign security roles, click a link in the Attachment Type Items column to view the settings. The Attachment Type Setting window opens.
- Click Save & Close to save and close the window, or click Close to close the window without saving any changes.
Identifies the selected attachment type. |
|
Select all roles that should have access to this type. A user will need to have at least one of the selected roles to select this type when attaching files, and access any attached files with this type. |
Attachment types that are no longer included in the currently selected Attachments list can be deleted using the Delete button. Note that deleting a type that has been used for any attachments will remove the restrictions on those attachments, making them visible to any user with general access to attachments.
To assist with locating transactions in the Submission / Policy List, fields from the attached workflow can be made available as optional columns.
Twenty columns can be added for text content (only the first three are displayed in the screenshot). These can be used for Drop-down, Label, Radio Buttons, Text Area, Textbox, and Textbox (E-mail) type fields. For Drop-down and Radio Button fields, the code for the selected item is displayed. |
|
Six columns can be added for decimal values (only the first three are displayed in the screenshot). There are three options to display a different number of decimal points (2, 4, and 8). Any digits after the selected number of decimal points are cut off, not rounded, but this is only for display and does not affect the stored value. |
|
Six columns can be added for integer values (only the first three are displayed in the screenshot). |
|
Three columns can be added for dates. |
These optional columns are available in the Submission /Policy List, and can be added to the grid using the Select Columns option in the context menu accessed by right-clicking a column header. For more information about customizing grids and saving the settings, see
Notes:
The labels for the dropdown fields in this panel are used as the column headers. The labels can be changed in the
Only form fields are available. Fields included in grids are not available.
When these settings are changed, only new submissions will display the optional fields. When the master cover is set to Live status, all existing submissions and policies are updated to display the appropriate data in the new columns.
Click Save to save the current settings.
Out of Sequence Endorsement and Adjustment Changes
When a new endorsement or adjustment transaction is created within a product that performs Out of Sequence (OOS) changes, changes are made to other transactions in the term. This section details the rules and effects of OOS transactions.
All bound endorsement and adjustment transactions with a later effective date are referred to as blocking transactions, and will receive any changes resulting from the new transaction.
Once the OOS transaction is created, the Effective Date can be modified, but only within the period between the previous and next Effective Dates for other transactions in the term.
When the Out of Sequence (OOS) transaction is quoted, Replacement versions of the blocking transactions are created and quoted. This produces the premium changes displayed in the Affected Transactions widget.
When the Out of Sequence (OOS) transaction is bound, the original blocking transactions are Voided, Offset transactions are created and bound, and the Replacement transactions are bound with the necessary changes.
Changes are applied according to the following rules.
- If the OOS transaction changes the main distributor, the replacement transactions receive the Term Distributor as the main distributor. Any additional distributors are added to the replacement transactions.
- If the client information is changed, the client information in the replacement transactions is copied form the core client record.
- Values that are changed in the OOS transaction are copied to the replacement transactions. The system does not combine changes from the OOS transaction and the blocking transaction, such as two increases of 5 resulting in a total increase of 10 in the replacement transaction.
- If a value is changed in the OOS transaction that was already changed in the blocking transaction, the value in the blocking transaction is kept for the replacement transaction.
- Files attached to File Upload fields in the OOS transaction are not duplicated in the replacement transaction.
- While validations and integrations are active while processing the OOS transaction, no validations are performed on the replacement transaction, and only integrations associated to the Bind action are performed.
Managing Grid Data in OOS Transactions
There are times where an OOS transaction requires changes to grid data. When this occurs, the system must determine what values to propagate forward for the resulting Replacement transactions. Otherwise, discrepancies or the duplication of data may occur.
To address this, a Business Key can be configured during grid configuration to uniquely identify each grid row.
When specified in the Grid Management page in Product Design, this field must contain a unique value for each row in the grid. This is used to uniquely identify grid rows for the purpose of OOSE processing and for comparing grid rows across transactions to determine the changes.
The system uses the Business Key to identify matching rows between the OOS transaction and the blocking transaction. Once these have been identified, the system can accurately render the grid data in the resulting Replacement transaction.
When adding a grid row in the OOS transaction, the fallback order for the evaluation of grid rows is as follows.
- The system first tries to identify matching rows by GUID. If identical GUIDs are matched, the system will create a single entry in the Replacement transaction. The operation for the identified duplicate rows ends here, even if a Business Key has been specified for this grid.
- Because the grid row GUID can change, for example when deleting and then re-entering a grid row, the system continues to evaluate the remaining grid rows by the Business Key values. When matching Business Keys are identified, the system recognizes that this represents a duplication of the same grid row and will only propagate this grid row once in the Replacement transaction. The system first evaluates for duplicate grid rows according to the GUID, and completes the evaluation according to the Business Key values.
- If a matching grid row is identified, the system recognizes the duplication and creates a single reproduction in the Replacement transaction. The addition of the grid row in the OOS transaction is recognized, and the system propagates the value of the OOS transaction forward.
- If a grid row is deleted in the blocking transaction and added back with new field values, and this same grid row is edited in the OOS transaction, the values replaced in the blocking transaction are propagated to the Replacement transaction.